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INTRODUCTION 


Through  the  years,  the  desiqn,  implementation,  and 
maintenance  ot  computer  information  systems  has  become  one 
of  the  most  important  elements  of  an  effective  organization, 
An  army' is  commonly  referred  to  as  "marching  on  its 
stomach".  An  organization  marches  not  only  on  the  content 
of  its  information,  but  also  on  how  it  accesses  that 
information  up  and  down  its  organizational  structure. 

Many  organ i z a t i ons  are  evolving  towards  Richard  Nolan's 
concept  of  "mature"  data  processing  users  CRef.  13. 

Computers  are  no  longer  used  gust  to  assist  the  operational 
managers  in  the  day  to  day  transactional  processing  as  they 
were  five  to  seven  years  ago.  Managers  at  all  levels  of  the 
organization  need  information  to  make  countless  decisions. 
Today’s  computer  technology  provides  the  capability  to 
re tr  1  eve  needed  information  from  throughout  the 
organ  i  cat  i  on.  However',  the  weak  link  is  the  compatibility 
of  data  and  data  structures  to  allow  access  to  the 
information  of  the  organization. 

Much  attention  has  been  given  to  the  development  -<nd 
improvements  in  computer  hardware.  These  ■.  ■••provements  have 
been  easy  to  observe.  Car!-  computers  that  contained  -mall 
.mounts  of  memor>  were  phvsicall  v  huge  and  eg* •  i  red  large 
in. es t  men  t  s  of  capital.  Management  concern  was  w 1 1  <<  keeping 


the  computer  busy  by  processing  millions  o-f  transactions 
that  were  relatively  easy  to  program.  Today,  processors 
which  possess  almost  a  million  bytes  of  computer  memory  are 
commonplace  on  workers’  desks  throughout  the  organi z at  1  on . 
Computers  have  become  smaller,  cheaper,  -faster,  more 
reliable,  and  easier  to  maintain  than  earlier  models.  Now 
management  concern  is  with  coordinating  all  the  computer 
systems  in  an  organization  in  order  to  support  and  control 
an  effective  overall  information  system. 

The  Naval  Supply  Systems  Command  (NAVSUP)  is  similar  to 
any  large  organization  with  computer  information  systems. 

In  the  mid  1 ’60' 5,  NAVSUP  developed  three  major  financial 
and  inventory  control  systems  to  provide  support  for  its  tri 
level  organization.  They  are  the  Shipboard  Uniform  Automated 
Data  Processing  System  <SUADF'S'»,  the  Uniform  Automated  Data 
Processing  System  for  Stock:  Points  <UADP3-SP>  ,  and  the 
Uniform  Inventory  Control  Point  sytem  (UICP) .  These  systems 
were  designed  using  second  generation  hardware  and  cof tware 
techniques  with  major  emphasis  on  individual  file 
processi nq . 

Today,  all  three  of  these  major  systems  are  being 
redesigned  to  utilize  the  state  of  the  art  hardware 
technology.  NAVSUP  has  the  unique  opportunity  to  design 
these  systems  to  provide  integration  throughout  the 
organization  and  to  take  an  i  •••portent  step  towards  realizing 


a  true  corpor  ate  inf ormation  system  allowinq  top  management 
access  to  the  information  that  they  need. 

This  thesis  will  discuss  the  problems  of  coordinating 
the  design  of  the  three  systems  experienced  by  NA'.'SUP  with 
an  emphasis  on  the  role  of  data  administration  in  the 
overall  concept  of  information  systems.  Much  attention  will 
toe  given  to  the  concepts  of  software  design  including  the 
basics  of  Information  Engineering  which  is  being  used  by  the 
Fleet  Material  Support  Office  i.FMSO)  ,  the  central  desiqn 
activity  for  UADF'S-SP  and  UICP.  After  the  discussion  of  the 
three  replacement  systems,  the  need  for  a  strong  data 
administration  activity  at  NAVSUP  Headquarters  to  allow  for 
.erticul  integration  will  be  emphasized. 


I  I  .  BACKGROUND 


A.  NAVSUP  ORGANIZATION 

NAVSUP  supports  logistic  operations  through  a  tri-level 
organisational  structure  as  shown  in  Figure  1.  The  bottom 
layer  if  the  ship  or  squadron  supply  department  which 
maintains  an  inventory  of  up  to  100,000  line  items  for 
issue.  If  a  needed  part  is  not  available,  a  referral  is 
sent  to  the  next  level,  the  nearest  stock  point  (Naval 
Supply  Center  or  Depot).  A  stock  point  carries  an  inventor y 
of  between  PO,000  and  1,500,000  items  and  satisfies 
approximately  75’/.  of  the  referral  requests  it  receives.  The 
unfilled  referral s  are  sent  to  either  the  Aviation  Supply 
Office  (ASQ)  or  the  Ship  Parts  Control  Center  *  SF'CC  >  ,  the 
third  le-el  in  the  logistic  chain.  AS0  and  SF'CC  do  not 
stod  any  parts  for  issue.  They  function  as  inventory 
control  points  *  I  CPs)  and  monitor  the  worldwide  •  nventorv  r.f 
supply  parts,  the  status  of  depot  level  repairables,  and  i be 
contracts  f or  new  procurements.  The  two  ! CF ’ s  handle  o-er 
2,000, 000  demands  everv  month.  The  l CP  will  direct  the 
issue  of  a  needed  pert  from  any  supply  source  throughout  the 


wor  1  d 


Figure  l  — Logistic  Support  Qrqam  2  at  i  on 


Each  level  in  the  supply  chain  utilizes  a  different 
sophist  1 ca  ted  automated  inventory  control  system.  These 

•  omp  liter  sv  stems  were  effective  in  the  oast  in  assistinq  the 
Mwvsup  activities  in  pert or mi nq  thei r  missions.  However  , 

*  or  the  last  ten  years,  the  pace  of  operations  and  the  sheer 
size  of  the  computin'!  Iced  have  created  a  cosperate  need  tor 
modern  information  systems  at  all  ie-eis.  eng  1  !:  1  onal  I  v  . 
f'lAVSl.iF'  headquarters  now  need  -  access  to  information  at  ->11 
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aster  1  ban  what  1 s  current  1  .  a  -ao  J able. 


much  * 


The  Navy's  in-formation  needs  have  changed  dramatically 
since  the  earlier  systems  were  developed.  They  were 
designed  as  report  generators  executing  in  hatch  mode  to 
provide  page  upon  page  o-f  output  needed  by  i  n venter  v  control 
clerks.  This  satisfied  the  operational  level  of  management 
information  needs.  Upper  and  middle  management  do  not 
recei ve  „suf f i ci ent  information  from  these  systems  to  answer 
the  "what  should  we  be  doing"’"  and  "what  is  our  status  right 
now^"  type  questions.  For  NAVSUP,  the  need  for  integrated 
information  systems  was  made  obvious  during  1999  and  1980 
when  naval  units  were  required  to  operate  in  the  Indian 
Ocean  for  extended  periods  outside  their  normal  logistics 
chain.  Top  management  had  difficulty  in  getting  up  to  date 
information  from  the  ships,  stock  points,  and  ICF's  to  make 
the  many  decisions  to  adequately  support  all  units.  The 
lack  of  integration  among  the  three  major  information 
systems  has  become  a  chief  concern  of  the  Inventory  and 
Information  Systems  Directorate  ( SUP-04 )  at  NAVSUP 
Headquarters . 

B.  INFORMATION  SYSTEMS 

An  information  system,  in  general ,  consists  of  hardware, 
software,  data,  personnel,  and  procedures.  Each  element 
must  interact  correctly  in  order  to  have  an  efficient  and 
effective  system.  With  the  remarkable  advances  in  the 
amount  of  computer  memory  available,  the  pivotal  element  has 


shifted  from  the  computer  processor  itself  to  the  data 
contained  within  a  system.  Data  is  now  viewed  as  a  valuable 
resource  to  be  shared  throughout  the  system.  The  user  must 
become  more  responsible  for  the  integrity  of  the  data  than 
was  reguired  by  the  older  systems.  This  concept  requires  a 
coordinated  effort  by  the  designers,  managers,  and  users  to 
ensure  gew  information  systems  will  satisfy  the  requirements 
of  individual  activities  and  allow  access  to  and  from  other 
information  systems.  This  need  for  integration  has  led  to 
the  development  of  a  new  methodolqy  for  systems  design  known 
as  information  engineering. 

Until  recently,  NAVSUF'  activities  at  each  level  were 
allowed  to  develop  information  systems  to  satisfy  their  own 
requirements  with  little  concern  for  interfacing  with  other 
systems.  This  "isolated"  design  methodology  evolved 
primarily  because  each  activity’s  data  processing 
requirements  centered  around  specific  functional  programs 
such  as  payroll,  personnel  accounting,  or  inventory 
management ,  Such  programs  were  developed  using  second 
generation  computers  and  were  designed  for  independent  file 
processing.  During  this  period,  the  Navy  implemented  three 
large  automated  logistics  systems  to  handle  uniform  data 
processing  requirements:  UICF  (with  UN I VAC  hardware'  +or 
the  two  inventory  control  points,  UADPS-SP  (with  Burroughs 
equipment  and  file  structures)  for  stock  points,  and  SUADPS 
with  UNI  VAC  hardware)  for  1  arge  fleet  units.  The  1-id  of 


compatibi 1 lty  among  these  systems  forced  NAVSUP  to  support 
many  redundant  applications  and  data  files.  Because  of  the 
size  of  these  computer  systems,  the  immense  investment  in 
maintaining  and  expanding  them  through  the  years,  and  a  long 
period  of  ABF'  funding  shortfalls,  the  Navy  was  prohibited 
from  replacing  its  outdated  equipment  and  processes  even 
though  newer  hardware  and  more  efficient  applications 
ex i sted . 

C.  NAVSUP  MODERNIZATION  PROGRAMS 
L .  Over vi ew 

NAVSUP  is  now  involved  with  modernizing  its  three 
major  information  systems  to  catch  up  with  the  technol ogi cal 
advances  of  the  past  twenty  years  and  allow  managers  at 
every  level  to  have  access  to  the  information  thev  need. 

The  programs  are  :  UUCP  RESYSTEM I Z AT TON,  UADPS  Stock  Point 
A  OF'  Replacement  (SPAR',  and  SUADPS  Real-Time.  The  first  two 
systems  are  being  designed  by  FMSO  in  Meehan i csburg , 
Pennsylvania  using  many  of  the  techniques  of  information 
engineering.  SUADPS  Real-Time  is  under  the  cognizance  of 
Navy  Management  Systems  Support  Office  (NAVMASSQ' ,  Norfolk, 
Virginia.  It  is  a  much  smaller  system  and  has  kept  man v  of 
the  traditional  file  design  techniques.  Figure  2  summarizes 
the  i  ey  elements  of  the  three  projects. 


SUADPS  Real-Time 


SUADPS  Real-Time  is  a  user  oriented  on-line 
interactive  supply  and  financial  system  which  utilizes  the 
SNAP'  I  computer  hardware  to  support  designated  shipboard. 
Marine  Air  Group  (MAG)  Supply  Departments,  and  certain  Shore 
Intermediate  Maintenance  Activities  (SIMA)  mission  support 
functions.  It  males  maximum  use  of  the  interactive 
capabilities  of  the  hardware  in  data  input,  data  update,  and 
data  base  query  operations.  It  replaces  the  original 
version  of  SUADPS  which  was  a  card  oriented  batch  system 
designed  for  the  UN I VAC  1500  system. 

The  primary  reason  for  the  development  of  SUADPS 
Seal -Time  is  to  take  advantage  of  the  upgrade  in  computer 
processing  capability  made  possible  by  the  Shipboard  Non 
Tactical  ADP  Program  for  larqe  ships  (SNAP  I).  SNAP  I 
removed  the  second  generation  U1500  systems  from  the  field 
activities  and  replaced  them  with  a  fourth  generation  mini 
computer,  the  Honeywell  DF'S-6.  The  DF'S-6  increases  the 
memory  capabi 1 ty  from  16,000  to  2,000,000  bytes  and  provides 
for  on-line  storage  of  at  least  12,000,000  bvtes.  With  this 
quantum  leap  in  computer  capacity,  the  capability  for 
creating  a  more  effective  system  became  a  reality.  SUADPS 
Peal -Time  is  one  of  several  on-line  systems  being 
implemented  on  the  SNAP  I  systems.  According  to  its  charter 
LPef.  23,  it  is  designed  to  s 
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a.  Reduce  the  time  and  effort  required  to  process 
supply  transactions  and  to  access  supply 
in-formation. 

b.  Improve  supply  response  times  tor  orqani zati onal  and 
intermediate  level  material  requirements. 

c.  Improve  utilization  of  fleet  operations  and 
maintenance  -funds. 

d.  Improve  accuracy,  consistency,  and  timeliness  of 
supply,  financial,  and  logistics  data. 

e.  Provide  a  direct  interface  with  maintenance  systems. 

An  important  element  missing  from  this  design 
criteria  is  the  need  to  interface  with  UADPS-SP  or  UIC-P. 
NAVMASSO  chose  to  continue  many  of  the  file  design 
techniques  of  the  old  SUADPS  system  to  allow  easier 
transition  to  the  new  system  and  interface  with  the  ship’s 
3M  maintenance  reporting  system.  This  has  resulted  in  data 
redundancy  and  lack  of  file  integration.  Many  processes  are 
duplicated  for  one  transaction.  Using  a  data  base 
management  system  <DBMS)  would  have  reduced  the  redundacy 
and  possibly  allowed  better  interaction  with  external 
systems.  Keeping  the  imbedded  tile  structures  has  also  made 
the  future  development  of  a  NAVSUF’  corporate  data  base  much 
more  difficult.  Other  factors  such  as  getting  a  system  out 
to  the  fleet  as  soon  as  possible  to  use  the  new  hardware 
took  precedence. 

NAVMASSO’ s  implementation  plan  involves  phasing  in 
■ersions  of  the  new  SUADPS  RT  as  they  are  developed  and 
had  fitting  previously  installed  systems.  Unf  oi-t  unetel  v  , 
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users  are  discovering  many  bugs  in  the  system.  This 
decreases  their  faith  in  the  system  and  increases  their 
reluctance  to  change  from  many  outdated  processing  methods 
such  as  using  punched  card  input.  Currently,  USS  Dixon 
lAS-37)  homported  in  San  Diego  has  the  latest  version  of 
SUADF'S  Real-Time  on  the  west  coast.  Due  to  the  phase-in 
approach,  stock  control  personnel  are  forced  to  perform  dual 
processing  until  final  system  development  is  completed  in 
approx i matel y  two  years.  The  dual  processing  involves 
entering  data  into  the  "real  time"  files  for  query 
processing  and  requisitioning  material,  then  downloading 
that  data  for  processing  to  the  "official"  data  files  for 
processing  by  the  old  SUADF'S  system  running  in  emulation 
mode.  While  the  old  system  is  ru.nninq,  the  ship  loses  its 
"real  time"  capabi 1 1 ti es.  Additionally,  requisitions  which 
must  be  passed  off -ship  are  being  prepared  and  submitted  in 
three  different  methods  which  varv  from  ship  to  ship 
depending  on  their  experience.  Requisition  processing  is 
accomplished  by  (1)  direct  input  into  a  Burroughs  terminal 
and  utilizing  a  fleet  on-line  program,  (.2)  submitting  a 
SUADF'S  tape  to  the  stock  point  for  UADF'S  processing,  or  <  3) 
writing  out  a  requisition  document  and  having  tne  stock: 
point  prepare  the  automated  requisition  card. 

SUADF'S  Real-Time  has  created  a  new  element  in  the 
shipboard  supply  department  operations  bv  giving  remote 
a*-  cess  to  its  supple  f  i  l  es.  Under  the  old  sue  OP  5 
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processing,  one  or  two  storekeepers  and  me  o<_  •  .  octroi 

officer  were  SUADPS  trained.  They  were  resprnsiole  me 
ensuring  that  supply  documents  were  '  Or>  ertl  .  prepared  tor 
submission  to  the  data  processing  di  vision.  utter  me 
inventory  programs  were  executed,  they  then  had  to  wo.rk 
error  listings  of  improper  transact  1 ons.  It  was  not 

r 

uncommon  for  a  single  transaction  to  require  two  weeks  o+ 
processing  before  being  completed  if  it  was  originally 
submitted  incorrectly.  In  the  meantime,  the  rest  of  the 
supply  department  was  working  with  printouts  of  the 
inventory  files  that  were  up  to  two  weeks  old.  With  SUADPS 
Real-Time,  all  storekeepers  will  be  involved  with  the 
inventory  data.  Remote  terminals  at  stock  control  and  most 
of  the  storerooms  will  allow  direct  on-line  processing  of 
receipts,  issues,  and  requisitions.  This  will  require 
SUADPS  training  for  ail  supply  personnel  to  ensure  data 
1 ntegr i ty . 

The  new  system  allows  output  of  requisition  files  to 
either  floppy  disk,  magnetic  tape,  or  punched  cards. 
Currently,  the  stock  points  are  only  capable  of  using  tape 
or  punched  cards.  Because  of  initial  problems  with  the 
UADPS— SP  system  reading  the  Honeywell  tapes,  the  majority  of 
ships  with  SUADPS  Real-Time  are  reluctant  to  change  to  the 
new  technology  and  are  continuing  to  use  the  punched  card 
output  that  they  used  for  twenty  years,  i hi  3  severely  slows 
processing  time.  This  wi 11  continue  to  be  a  problem  until 


the  "second  generation  mentality"  is  removed  through 
training  and  hopefully  with  the  implementation  of  the  SPAR 
equipment  at  the  stock  points  which  is  being  designed  to 


allow  direct  transfer  of  requisitions  by  floppy  disks. 

3.  Stock  Point  ADP  Replacement  Project 

fhe  Stock  Point.  ADP  Replacement  Project  (SPAR) 
received  its  charter  from  NAVSUF'  in  March  1983.  It  has  two 
main  objectives:  (1)  replace  the  computer  systems  at  25 
major  data  processing  facilities  that  provide  services  to  -r2 
activities  which  utilize  the  Uniform  Automated  Data 
Processing  System  for  Stock  Points  <UADPS-SP) ;  (2)  the 

moderni  zat.  i  on  of  UADPS-SP  to  improve  the  level  of  supply 
support  provided  to  the  operating  forces  of  the  Navy. 
Deployment  of  new  hardware  and  software  will  extend  into  the 
1990 's  with  a  contract  life  of  24  years  to  allow  for 
technological  improvements  and  capacity  expansion  as 
required.  CRef.  31 

Stock  point  computer  systems  have  been  operating  at 
full  capacity  for  years.  Because  of  the  sheer  size  of  SPAR 
and  the  lead  time  for  system  acquisition  and  development, 
the  Navy  implemented  the  Navv  Stock  Point  Logistic 
Integrated  Communication  Environment  (SPLICE)  as  an  interim 
program.  The  primary  objectives  of  SPLICE  are  to  relieve 
the  saturation  of  computer  systems  current lv  at  the  stock 
points  and  to  provide  for  the  telecommunication  needs 


of  r  he 


modernized  UADPS.  SPLICE  was  envisioned  as  a  quick  stop-gap 


measure  to  allow  -for  a  controlled  redesign  effort  in  SPAR. 
However,  problems  with  the  establishment  of  network  protocol 
for  the  Department  of  Defense  Network  (DON)  has  delayed  the 
actual  implementation  of  SPLICE.  Meanwhile,  the  design 
phase  of  SPAR  has  pushed  forward. 

The  SPAR  project  involves  replacing  60  medium  scale 
computers  and  converting  or  redesigning  7800  programs  that 
contain  11.5  million  lines  of  source  code.  It  does  not 
include  the  redesign  or  conversion  of  the  hundreds  of  local 
programs  that  exist  throughout  the  system.  The  completed 
system  is  being  designed  to  efficiently  interface  with  both 
the  UICP  and  SUADPS  Real  Time  systems.  Since  it  is  such  a 
huge  project,  a  "risk  aversion"  attitude  has  partitioned  it. 
into  three  main  phases:  <t>  hardware  acquisition  with 

equipment  selection  now  scheduled  for  March  1987,  t.2> 

conversion  of  the  current  UADPS  svstem  to  execute  on  the  new 
hardware,  and  <  3  >  modernization  of  UADPS.  Each  phase  has  a 
separate  manager  at  NAVSUP  headquarter s. 

The  transistion  plan  for  the  replacement  project 
discussed  four  different  alternatives  tor  replacing  the 
current  software  including  standard  conversion,  generic 
CGy  01. ,  shell  or  bridges,  and  redesign.  An  initial  decision 
to  implement  SPAR  with  converted  software  vice  a  modernized 
Sr  stem  was  made  because  manv  of  the  desiqn  techniques  that 
tb-e  modern  i  z  at  l  on  team  will  use  are  a  radical  departure  from 


:v 


-*  A 


traditional  methods.  The  cost  of  having  the  system  -fail 
during  implementation  at  any  stock  point  is  deemed  too  high 
to  risk.  Also,  the  feeling  is  that  conversion  will  be  the 
quickest  method  to  get  the  new  hardware  to  the  activities. 

A  final  decision  will  be  made  in  late  1985  after  the 
redesign  team  at  FMSG  prepares  its  initial  package.  [Ref  41 
The  SPAR  redesign  team  at  FriSO  began  its  project  by 
preparing  a  functional  description  of  all  the  tasks 
performed  by  the  current  version  of  UADPS-SP.  Utilizing  a 
fourth  generation  software  design  tool ,  DATA  DESIGNER,  they 
compiled  the  logical  relationship  of  all  the  functions  and 
the  data  files  with  which  they  interact.  This  identified 
data  classes  with  one  to  one,  one  to  manv,  and  many  to  many 
relationships.  The  team  took  this  output  to  the  users  and 
asked  "Is  this  really  the  way  you  do  your  processing?"  At 
the  same  time,  they  queried  the  users  on  what  they  thought 
the  new  system  should  do.  This  bottom-up  design  method 
contradicts  one  of  the  key  elements  of  Information 
Engineering  (IE).  In  IE,  top  management  decides  what  the 
new  system  should  do  and  lets  the  design  wort  top-down  in 
the  conceptual  stage.  However,  (E  also  assumes  that 
corporate  headquarters  has  a  firm  description  of  its 
information  needs  included  in  its  strategic  plan.  The 
pressures  of  time  forced  FMSO  to  query  the  users  first,  mak 
managerial  recommendations,  and  forward  its  intentions  to 


NAVSUP  Headquarters. 


From  the  preliminary  results,  the  FMSO  team  has 
decided  to  proceed  with  a  phased  implementation  of  the 


redesigned  software  and  backfit  orqani 2 at  1 ons  with  the  new 
software  as  it  is  developed  instead  of  attempting  to 
prototype  all  of  the  chanqes  on  one  system.  This  is 
similiai;  to  the  SUABF'S  REAL-TIME  implementation  plan.  The 
major  difference  is  that  under  SPAR  there  will  be  no 
duplicate  processing  under  emulation  mode.  Currently,  the 
redesiqn  team  is  continuing  its  development  work  while 
serving  as  a  beta  test  site  for  a  new  fourth  generation 
software  desiqn  program. 

4.  Ll  I  CP  RESYSTEM  I Z AT I QN 

FMSO  has  also  been  tasked  with  designing  the 
modernized  software  for  the  inventory  control  point  (I  CP) 
level.  LIICP  RESYSTEM  I ZATION  or  RESOLICITATION  is  the  TCP 
version  of  SPAR.  Uniform  Inventory  Control  Point  < U I CP >  1 

a  collection  of  programs  very  similar  to  the  UADPS-SP 
system.  The  current  system  involves  IBM  hardware  at  two 
sites,  SPCC  1 n  Mechani csburg ,  Pennsylvania  and  ASO  in 
Philadelphia,  Pennsylvania.  RESYSTEMI ZATION  efforts  began 
in  1978  with  an  expected  completion  date  of  March  1R8R.  Tl 
project  has  already  selected  and  installed  IBM  3080/3090 
hardware. 

The  software  redesign  effort  began  before  the 
development  of  the  design  techniques  of  Inf ormati on 


Engineering.  However,  the  redesign  team  has  been  in  close 
communication  with  the  SPAR  team  and  would  like  to  integrate 
many  of  the  concepts  of  IE  into  their  project.  This  may 
prove  to  be  very  difficult  due  to  the  mechanics  involved. 
Currently,  the  project  is  also  geared  towards  a  phased 
implementation  with  the  financial  accounting  subsystem  being 
the  first  scheduled  to  come  on  line.  The  system  is  built 
around  the  IBM  IBMS  data  base  system  which  could  be  a 
problem  -for  integration  o-f  UADPS—SP  AND  UICP  data.  The 
interface  between  SPAR  and  UICP  is  deemed  critical  to  the 
future  development  of  a  corporate  data  base  capability. 
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III.  SOFTWARE  DEVELOPMEN T / I NFQRMA T I ON  ENG  I NEER I NG 


A.  BACKGROUND 

To  the  lavinan,  the  quantum  leap  in  computer  technology 
durinq  the  past  five  to  seven  years  has  been,  at  best,  mind 
boggling.  Much  attention  has  been  given  to  the  development 
and  improvements  in  hardware  which  have  been  easy  to 
observe.  Early  computers  that  contained  small  amounts  of 
memory  were  physically  huge  and  required  a  Urge  investment 
of  capital.  Today,  processors  which  work  with  almost  a 
million  bytes  of  memory  are  commonplace  on  workers’  desks  in 
almost  every  office  building.  Even  as  they  have  become 
smaller,  computers  are  cheaper,  faster,  more  reliable,  and 
easier  to  maintain  than  earlier  models. 

Unseen  to  most  people,  a  remarkable  change  in  the  manner 
in  which  computers  are  programmed  has  been  taking  place. 
Durinq  the  early  days  of  computer  programming,  the 
development  of  software  was  sever el „  j  j mi  ted  bv  the 
capabilities  of  the  computer.  As  the  computer  became  less 
'"estric  1 1  ve,  the  programs  became  more  comple  because  man 
demanded  more  from  this  electronic  resource.  However,  unit) 
recently,  the  manner  in  which  people  approached  the 
programming  problem  remained  the  same.  Most  software:-  was 
developed  top-down  and  was  application  or  tunc  1 t  or  orient,  ed , 
But  as  demand  for  sol  ut  i  oi  i  *  to  'nor  a  ,  un.v  a  i  prob  l  ems 


increased,  the  methodology  of  programming  has  slowly  evolved 
into  an  "information  enqineerinq"  project.  To  appreciate 
the  power  and  complexity  of  information  engineering,  a  brief 
description  of  the  earlier  methods  is  needed. 

Ft.  ERAS  OF  SOFTWARE  DEVELOPMENT 

The  evolution  of  computer  systems  and  software 
development  has  been  character i zed  by  three  eras  i Ref .  5  1. 

En  the  first  era,  programming  was  initially  accomplished  by 
hardwiring  the  computer.  Each  different  application  being 
executed  on  the  computer  required  a  complete  rewiring  of  the 
computer.  The  programmers  were,  in  fact,  electrical 
engineers.  Once  the  second  generation  computers  were 
developed,  non-engineers  became  involved.  The  use  of 
compilers  and  higher  level  programming  languages  gave 
programmers  much  more  flexibility.  But  ^ or  a  period  of 
twenty-five  .ears,  all  programs  we»  e  developed  to  sol  - e  a 
specific  problem.  Much  redundancy  in  che  proqr emminq  effort 
e-  l  sted.  h],  yo,  there  were  many  wavs  to*  approach  the  same 
problem.  Programmers  used  different  techniques  and 
algori  trims  and  most  programs  had  -erv  limi  ted  di  strj  but  ion. 

The  second  era  reflected  si  gni  «• 1  c-.-n  i.  i  .--.g  in  the 
capabilities  and  f  1“  ]  i~  O  i?  O  Cl  *  J  0  •  pi  L*  t  td  r ~  *•  j  rj.  V..  ►  ■  ff«  vd  y  Cjj  wipw 

were  no**  h^aj  nq  i.i e d  dy  »tio«-"o  than  one  person  ::~«r  ion 

~.j  orngr^Hia  h-ACj  1.0  ho  incf «  f  i  O  1  b  1  ^  oduC  +'  5JO  <  1 


testing,  and  evaluating  before  being  used. 


Libraries  of 


common  programs  became  necessary.  However  most  software 
development  still  was  application  oriented,  and  the 
applications  were  becoming  more  and  more  complex.  The  cost 
of  software  development  and  maintenance  began  to  skyrocket, 
and  soon  exceeded  hardware  costs.  During  this  "growth" 
stage  of  data  processing  development,  a  better  method  of 
programming  had  to  be  found  to  control  the  escalating  costs. 
Data  processing  experts  such  as  C.F.  Gibson  and  Richard 
Nolan  voiced  their  concern  over  the  uncontrollable  growth  in 
data  processing  requirements  and  tried  to  provide  industry 
with  guidelines  towards  a  "mature"  DP  environment  [Ref.  6  3. 
Many  of  their  concerns  became  real  as  computer  processing 
moved  into  the  third  era. 

The  third  era  of  software  development  began  with  the 
arrival  of  microprocessors  and  distributed  computing  systems 
and  continues  today.  The  need  for  software  greatly  exceeds 
the  personnel  and  technical  resources  available.  The  fact 
that  many  functions  are  now  hardwired  into  the  processors 
helps,  but  the  computing  world  can  no  longer  afford  the 
luxury  of  putting  months  or  years  into  developing  a  program 
that  does  not  satisfy  current  requirements.  Many  businesses 
are  discovering  how  important  the  computer  can  be  to  both 
[heir  day-to-dav  operations  and  to  their  long  range  planning 
ef  forts.  However,  many  users  are  frustrated  with  the 
traditional  programming  requirements  and  limitations. 


Charles  Rubin  states  "Ideally,  what’s  needed  Is  software 
with  a  flexible  command  processor  that  would  let  the  user 
define  .  .  .  the  way  the  user  1  lies  to  communicate  ,  .  .  The 

solution  is  beyond  our  current  means,  although  there  are 
some  integrated  packages  on  the  horizon  that  promise 
’modeless’  operation  ....  [Ref.  7.1  This  "need"  requires 
a  new  method  of  programming.  A  major  step  in  satisfying 
that  requirement  is  the  emergence  of  software  engineering. 

C.  SOFTWARE  ENGINEERING 

Previous  programming  techniques  centered  on  a  flowchart 
approach  that,  was  concerned  with  procedural  or  "how  to" 
questions.  Software  engineering  is  geared  towards  a  "what 
to  do"  question  and  is  functionally  oriented.  To  ensure 
efficiency  and  effectiveness  of  the  software  product,  a 
great  deal  of  planning  is  required.  Hence,  the  engineering 
attitude  is  employed.  It  is  a.  methodology  that  uses 
techniques  that  are  application  independent,  it  is  modeled 
on  the  time-proven  techniques,  methods,  and  controls 
associated  with  hardware  development  and  is  centered  on 
three  key  objectives:  < 1 )  a  well  defined  methodology  that 
addresses  a  software  life  cycle  of  planning,  development, 
and  maintenance,  <2>  an  established  set  of  software 
components  that  documents  each  step  m  che  life  ode  and 
shows  traceabi 1 i ty  from  step  to  step,  and  <  a  set  of 


predictable  milestones  that  can  be  reviewed  at  regular 


intervals  throughout  the  software  life  cycle,  CRef.  S3 

The  three  phases  of  a  software  life  cycle  are  the  key 
elements  of  software  engineering.  The  planning  phase 
includes  software  planning,  software  requirements  analysis 
and  definition,  and  a  review  of  the  software  requirements 
specification.  From  the  spec i f 1  cat  1 ons  generated  during  the 
planning  phase,  deliverables  are  created  during  the 
development  phase.  This  phase  includes  two  software  design 
steps,  codinq,  unit  testing,  integration  testing,  and 
validation  testing.  The  final  phase  is  the  maintenance 
phase  which  involves  maintaining  code  or  modifying  the 
software  to  ensure  its  reliability,  effectiveness,  and 
relevance.  Today,  40%  to  -T0V.  of  a  compan  ■  '  s  programming 
effort  is  involved  with  software  maintenance.  CRef  9  3  The 
large  amount  of  maintenance  during  the  life  cycle  of  the 
software  is  often  overlooked  during  f he  planning  phase  and 
resources  area  not  available  when  needed. 

Software  engineering  is  definite! v  impro- i nq  the 
effectiveness  and  reliability  of  many  programming  projects. 
But  it  is  still  a  traditional  programming  methodology  in  the 
sense  that  large  teams  of  programmers  are  required  as  «<el  1 
as  considerable  time.  This  does  not  solve  the  problem  of 
today’s  users  who  require  the  capabi J i t v  to  i ns tantaneousl v 
answer  scores  of  questions  regarding  a  wide  range  of  data. 
They  cannot  afford  to  wait  *  or  a  proqr  ammi  no  ream  1;o  pro~i.de 


them  with  a  software  tool. 


Information  engineering 


represents  a  radical  crhanqe  in  program  design  that  will  in 
effect  take  the  responsibility  for  the  majority  of 
programming  away  from  the  application  programmer  and  place 
it  in  the  hands  of  the  user. 

D.  INFORMATION  ENGINEERING 

Information  Engineering  >  IE)  is  a  discipline  that  is 
broader  than  software  engineering  and  encompasses  all  the 
interrelated  disciplines  necessary  to  manage  an  effective 
data  center.  it  ties  the  desiqn  of  the  data  center  square! 
into  the  corporate  planninq  processes  of  each  organization. 
A  mature  organization  lives  and  dies  on  its  data.  Contrary 
to  software  engineering  which  focuses  on  the  logic  used  in 
computerized  processes,  information  engineering  is  primaril 
concerned  with  how  data  is  created,  updated,  and  used. 
Earlier  programming  methodologies  were  designed  around 
static  procedures.  IE  maintains  a  basic  premise  that  the 
type  of  data  used  in  an  enterprise  do  not  change 
significantly  while  procedures  using  the  data  will. 

1 .  Building  Blocks 

There  are  nine  basic  building  blocks  denned  for 
information  engineering  as  outlined  in  Figure  G.  Each  bloc 
is  dependent  on  the  firm  development  of  its  predecessor s. 


They  are* 


a.  Strategic  requirements  analysis 

b.  Information  analysis 

c.  Data  modeling 

d.  Procedure  formation 

e.  Data  use  analysis 

f.  Distribution  analysis 

g.  Physical  data  base  design 

h.  Program  spec  1 f i cat i on  synthesis 

1.  Application  generation  without  programmers 

The  strategic  requirements  analysis  bloc!  is  the  most 
important  and  the  most  overlooked  portion  of  IE.  In  this 
block,  the  overall  objectives  of  the  enterprise  and  the 
information  needed  to  accomplish  those  objectives  are 
determined.  Many  organ i z at i ons  have  learned  the  hard  wav 
about  the  wastefulness  of  application -software  created  to 
generate  paperwork:  and  give  the  managers  little,  if  any, 
benefit.  Once  organizational  objectives  have  been 
determined,  the  second  block:  performs  a  top-down  analysis  of 
the  types  of  data  that  must  be  kept  and  how  they  relate  to 
one  another.  This  is  a.  critical  process  because  the 
cornerstone  of  information  engineering  is  that  data 
structures  will  remain  stable.  During  the  third  step,  'lata 
modeling,  a  detailed  logical  data  base  design  is  created. 

The  i  ev  is  that  the  data  is  structured  independent  of  how  it 
will  be  used.  The  fourth  block,  procedure  formation, 

■  oncerns  the  events  that  change  or  use  the  data  base.  These 
procedures  can  and  should  be  designed  and  programmed  by  the 
users.  To  enable  non-programming  personnel  to  accomplish 
rtm  s ,  j  n+ormat i on  engineering  is  strongl y  dependent  upon 
rmer-Hi  generation  proqrammi  nq  languages  which  are  basically 


non-procedur al  and  allow  codinq  in  Engl ishi ike  statements. 
Additionally,  there  is  the  capability  -for  automatic  code 
generation  using  the  procedure  charts  created  during  this 
b 1 ock  . 

The  -fifth  and  sixth  blocks,  data  use  analysis  and 
distribution  analysis,  prepare  the  data  organization  for  the 
physical  data  base  design  step  of  block  seven.  In  earlier 
methodologies,  the  physical  structure  of  the  data  was 
dictated  by  the  application  being  programmed.  Block  eight, 
program  spec  1 f 1 c a 1 1  on  synthesis,  integrates  the  different 
procedures,  documents  any  data  changes,  and  creates 
functionally  cohesive  program  code.  Finally,  block  nine 
represents  the  capability  of  application  development  without 
programmers  in  the  sense  of  dedicated  programmers  working  as 
a  team.  In  this  block  non-procedur al  languages  allow  the 
user  to  answer  queries  on  the  data  base,  model  "what  if" 
questions,  streamline  reports,  and  generally  get  to  the  data 
they  need.  Non -procedural  languages  differ  +rom  procedural 
!.  snquaaes  in  the  sense  that  a  procedural  1  anquaqe  specifies 
how  something  is  accomplished.  A  non --procedure  l  language 
specifies  what  is  accomplished  but  not  how  in  detail. 
Application  development  without  programmers  is  probabl s  the 
most  important  and  exciting  element  of  IE.  ! he  vast  back  1 oq 
m  application  development  in  most  orqani cations  has 
severely  restricted  the  flow  of  information. 


By  using  all  of  the  above  blocks,  corporations  can 
develop  -flexible  systems  which  meet  overall  organizational 
information  needs  much  more  rapidly  than  by  using 
traditional  design  methods  and  at  an  overall,  lower  cost. 

[  R  e  f  .  1 0 1 

3 .  L  i  f  e  C  v  c  1  e  Stages 

Software  engineering  assumes  a  life  cycle  of  three 
distinct  phases:  planning,  development,  and  maintenance. 
Information  engineering  decomposes  the  life  cycle  into  eight 
stages:  il)  Business  strategy  planning,  <2>  Information 

strategy  planning,  (3)  Business  area  analysis,  <41  Business 
system  design,  (51  Technical  design,  o)  Construction.  (7) 
Transition,  and  (8)  Production.  Each  of  these  stages  has  a 
building  block:  that  addresses  its  main  functions,  A  key 
element  is  the  existence  of  a  data  dictionary  or 
encvcl opedi a  that  is  referenced  during  each  one  of  the  life 
c.-cle  stages.  Without  a  good  oaf  a  cnctionar- ,  information 
eng  i  oeer  i.  ng  wou  1  d  be  i  mpossi  b  1  e . 


STRATEGIC 


REQUIREMENTS 


PLhNN  I  N(3 


3.  Data  Dictionary 

There  are  basically  tour  classes  ot  data 
environments.  Early  proqrammi nq  methods  involved  o nlv  the 
first  class;  tiles.  The  second  class,  application  data 
bases,  include  data  bases  designed  +  or  separate 
applications.  The  third  and  fourth  classes,  subject  data 
bases  and  information  systems,  require  an  enormous  amount  of 
sharing  ot  data,  attributes  and  it  uncontrolled  can  become 
unmanageable.  The  purpose  ot  a  data  dictionary  is  to 
control  that  data.  James  Martin  defines  a  data  dictionary 
a.s  "  a  tool  which  lists  all  -fields  that  are  used,  their 
definitions,  how  and  where  they  are  used,  and  who  is 
responsible  tor  them.  All  fields  in  all  locations  are  in 
the  data  dictionary.  "  II  Ref.  Ill  The  data  administrator 
needs  the  data  dictionary  to  enforce  agreement  on  the 
definition  of  each  field  tn  order  to  ensure  compat i b i 1 i t y  of 
the  data  throughout  the  corporation. 

A i  iser  Invol  vement 

another  major  difference  between  tradi.  >:  i  oral 
software  development  techniques  and  information  engineering 
is  the  degree  of  user  j.  nvol  aement .  In  the  past,  the  user 
filled  out  a  form  stating  his  application  requirement  and 
sometime — on  the  average  of  three  or  tour  -ears  later — a 
piece  of  output  might  show  up,  But  in  \ n * or mat . i on 
engineering,  the  ■ :  :er  i  s  n  >  rec  •'  I  ■  n  ••  o  1  .  eo  in  each  ot  fne 
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stages. 


For  instance 


in  strategic  requirements  planning. 


senior  management  must  be  involved  to  ensure  the  correct 
objectives  and  direction  of  the  organization  for  the  future 
are  properly  communicated.  In  information  analysis,  the 
user  is  primarily  responsible  for  the  completeness  and 
accuracy  of  the  organizational  data  base.  Finally,  in 
application  development  without  programmers,  the  user 
creates  and  utilizes  the  applications  he  needs  to  get 
results.  This  method  of  user  involvement  leads  to  a.  more 
flexible  environment  in  which  changes  can  be  made  easily  and 
q  u  l  c  T  1  y  . 

5.  Six  Stages  of  Growth  in  Data.  Processing 

A  final  differentiation  between  the  data-or i ented 
analysis  of  information  engineering  and  the 

procedure -or i ented  analysis  of  software  engineering  can  be 
=hown  by  discussing  the  effects  of  the  six  stages  of  growth 
in  data  processing  identified  by  F I  chard  Nolan  and  shown  in 
Figure  4  CRef.  123.  During  the  first  two  stages,  initiation 
and  contagion,  the  data  processing  department  is  concerned 
with  automating  functional  cost  reduction  applications  of 
specific  areas  such  as  accounting  or  inventory  control  .  I 
all  goes  well,  additional  requirements  are  considered, 

During  the  third  stage,  control,  the  DP  department  * i ods 
itself  unable  to  I  asp  pace  with  requi  r ements.  Often  this  is 
caused  bv  the  lad  of  an  overall  pi  an  throughout  the 


corporation  for  utilizing  data  processing.  During  the 
control  phase,  management  upgrades  documentation  and 
requires  formalized  justification  for  future  applications. 
Integration  i s  the  fourth  phase  and  is  marked  bv  a 
fundamental  change  in  the  way  applications  area  developed . 
Data  is  consol i dated .  in  the  fifth  stage,  data 
aomi m strat i on ,  the  organization  nas  a  wel 1 -devel oped  data 
base.  In  the  final  stage,  maturity,  the  data  processing 
function  "mirrors"  the  wav  the  organization  operates  and  all 
is  right  in  the  world. 

Organizations  in  stage  1  or  2  can  successfully 
utilize  procedure-oriented  analysis  and  design  techniques, 
w  more  mature  organization  must  use  the  data-oriented 
techniques  because  procedure-oriented  techniques  make  it 
virtually  impossible  to  identity  data  redundancy  which 


e  i sts  throughout  the  organization. 
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The  traditional  methods  of  software  development  are 
still  important  to  smaller  applications  and  to  organization 
jest  beginning  to  utilize  data  processing.  Information 
engineering  was  not  created  to  replace  those  methods.  The 
primary  goal  of  information  engineering  is  to  give  larger 
or gam z at  1 ons  the  capability  to  design  data  processing 
systems  that  support  the  organization’s  objectives  and 
capitalize  on  the  »alua  of  the  data  resource.  Corporations 
such  as  E'\on  and  government  agencies  such  as  the  Naval 
Supply  Systems  Command  have  endorsed  the  concept  of 
information  engineering  and  are  currently  involved  in 
projects  based  on  its  methodologies.  The  “mature" 
organization  of  the  future  is  closer  to  becoming  a  reality. 


IV 


data  ADMINISTRATION  and  vertical  integration 


A.  OVERVIEW 

The  design  of  modern  information  systems  is  far  more 
complex  than  any  project  most  organizations  have  previously 
attempted.  As  an  organisation  moves  through  Nolan's  stages 
of  aDP  evolution,  it  j  .aore  di  +  •*■  1  cul  t  to  change  its  ADR 
structure  to  <- 1 1  i  ts  i  nf  .or  mat  l  on  needs.  No  simple  tools 
exist  to  assist  corporate  managers  in  planning  the 
transition  to  the  r-e-t  phase.  Techniques  such  as  life  cycle 
planning,  stages  of  growth.  Business  Systems  Planning  and 
crirical  success  *  actors  all  lack  some  integral  elements  and 
are  not  totally  effective  in  today's  highly  technical, 
complex  1  n  tor  mat  i  on  world  L'R'ef.  13  3.  In+ormat  l  on 

Engineering  is  the  latest  attempt  at  successful  planning  of 
i  n  or  mat  i  on  needs. 

nr*  orqani  cation  cannot  rel  >•  so)  el  v  on  the  concept’s  of 
■  r<+  or  mat.  i  on  Eng  i  neer  i  ng  in  creating  information  systems.  IE 

-jiii_.il !  g  be  .  j  ewed  as  the  nucleus  •■*+  a  variety  of  data, 
processing  tools  or  techniques  that  when  thoughtfu.il  - 
integrated  furnish  the  organisation  with  an  effecti  v  f?  3  *»■’  hr  "t  (Ti 
that  handles  information  needs  now  and  will  allow  sufficient 
pansi  on  to  meet  a)  1  suture  requirements.  The  following 
,if  _  i:nmp  n-f  the  iiia'"-  componen  i  s  of  a  complete  information 
:  as  shown  in  figure  : 


1.  Information  Centers 

2.  Fourth  Generation  Languages 

3.  Expert  Systems 

4.  Computer  Graphics 

5.  Programming  Languages 

6.  Database  Management  Systems 

7.  Data  Dictionaries 

8.  Data  Administration 

Most  of  these  components  are  software  tools  that  aid  the 
system  ^developers  or  allow  easier  retrieval  of  data  by  the 
users.  The  last  component.  Data  Administration,  is  a 
collection  of  management  functions  that  when  properly 
performed  significantly  ease  the  effort  required  in  an 
Information  Engineering  project. 


B.  DATA  ADMINISTRATION  FUNCTIONS 

Data  Administration  is  best  described  as  the 
responsibility  for  planning,  coordinating,  and  managinq  an 
organization's  data.  Basic  functions  to  support  that 
responsibility  have  evolved  from  administrative  and 
technical  issues  involved  with  data  base  administration. 
The  concept  of  Data  Administration  is  less  than  ten  years 
old  and  is  far  from  being  a  defined  entity.  Most 
definitions  of  Data  Administration  embrace  at  least  ti«e 
areas:  strategic  data  planning,  data  modeling,  data 
conventions  and  standards,  data  interchange  and  tools 
management.  An  overall  goal  should  be  the  establishment  o 
policies  and  guidelines  for  the  management  of  data  as  a 
valuable  corporate  resource.  The  following  list  of  duties 
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of  a  data  admini strator  is  representat i ve  of  those  found  on 
position  descriptions  for  a  variety  of  companies. 

Manages  the  development  of  standards,  methods,  and 
guidelines  for  data  planning,  analysis,  data  modeling, 
documentation,  and  logical  database  design. 

Manages  the  coordination  between  users,  project 
management,  analysts,  and  management. 

Manages  the  logical  database  designs  and  the  use  of 
logical  design  software. 

Manages  the  establishment  of  the  Data  Dictionary  and 
develops  standards  for  its  use. 

Flans  and  manaqes  the  education  of  the  staff  on  data 
planning,  analysis,  modeling,  documentation,  and 
logical  design. 

Manages  the  staff  in  providing  data  modeling  support 
to  all  project  team  system  development  efforts. 

Provides  loqical  database  designs  and  performance 
specifications  to  database  administration  and  verifies 
any  required  database  design  changes  for  the  project 
and  user  management. 

Provides  an  awareness  of  contemporary  methods  of  data 
modeling  and  evaluates  their  application  in  the 
current  organizational  setting. 

Manages  the  security  and  privacy  of  the  data  in  all 
logical  design. 

Manages  the  maintenance  of  the  strategic  plan. 

Provides  the  resolution  of  all  data  definition  and 
usage  issues. 

Originally,  data  administration  was  thought  of  as  a 
purely  technical  function  having  primary  responsibility  over 
the  effectiveness  and  efficiency  of  data  bases  and  database 
management,  systems  *  DBMS )  [Ref.  14.1.  However,  corporations 


soon  found  that  merely  appointing  someone  to  be  in  charge  of 


data  bases  left  a  void  in  the  overall  management  of  data. 

The  data  admi ni strator  definitely  needs  to  possess  two  types 
of  talent:  administrative  and  technical. 

Administrative  skill  is  required  to  handle  management 

and  policy  affairs,  to  interact  with  various  groups  of 
✓ 

concerned  and  affected  people,  and  to  define  what  should  be 
in  the  organization’s  data  bases.  The  technical  skills  are 
required  to  determine  implementation  issues  relevant  to  the 
specific  data  bases  and  to  define  how  the  organization  data 
bases  will  be  structured  and  accessed. 

The  functions  of  data  administration  (DA)  are  often 
combined  with  those  of  database  admi m str at  1  on  (DBA)  in 
organi zati ons  where  the  same  person  performs  both  sets  of 
functions.  Many  organ i z at i ons  consider  the  DA  to  be  simply 
the  chief  DBA.  For  those  organizations  moving  towards  the 
maturity  phase,  combining  Data  Administration  and  database 
administration  functions  is  not  realistic.  Those 
organ i zat 1 ons  require  the  DA  to  have  estensi ve  knowledge  of 
the  organization  and  its  overall  composition.  For  instance, 
tn  Information  Engineering,  the  Data  Admi ni strator  would  be 
fully  involved  in  the  first  three  steps:  strategic 
requirements  planning,  information  analysis,  and  data 
modeling.  There  are  few  data,  base  administrators  that 
possess  the  necessary  sk ills  to  proper ! 
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execute  those 


■functions  as  well  as  have  the  time  to  adequately  control  the 


data  bases. 

The  combination  of  these  skills  or  rather  the  lack  of 

combination  often  determines  the  placement  of  the  data 

admi ni str at  1  on  function  within  the  orqani z at i on ’ s  structure. 

When  a  data  admi ni strat i on  shop  is  just  beginning  it  is 
* 

often  placed  lower  in  the  orqani rat i onal  heirarchv  because 
upper  management  is  unsure  ot  the  technical  aspects  of  its 
data  bases.  However,  to  ensure  better  data  consistency 
throughout  the  organization,  it  is  better  to  separate  the 
functions  of  the  data  administrator  from  the  database 
admi ni strator  and  place  the  DA  function  high  enough  in  the 
organi zat 1 onal  chain  to  be  effective  in  policy  matters  that 
affect  information  systems. 

C.  DATA  ADMINISTRATION  VS.  DATABASE  ADMINISTRATION 

Figure  £>  shows  a  comparison  of  data  admi  ni  strati  on  and 
database  administration  concerns  CRef.  151.  The  basic 
difference  involves  interfacing  with  a  particular  data  base 
vice  structuring  data  independent  of  a  data  base.  Data 
admi ni strat i on  must  be  concerned  with  the  long  term  design 
needs  and  utilizes  the  data  dictionary  as  a  primary  tool. 

The  data  administrator  has  the  overall,  responsibility  +or 
the  organization ’ a  data  resources,  and  is  responsible  for 
non  technical  activities  such  as  planning  and  defining  the 
conceptual  framework  for  the  overall  database  environment, 
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not  just  that  specifically  limited  to  DBMS  usage.  Database 

admi ni strat i on  is  concerned  with  the  efficiency  of  the 

actual  database  structure  and  DBMS.  The  DBA  is  the 

organization' s  leading  technical  expert  on  database  related 

activities  and  is  reponsible  for  the  day-to-day  operation  of 

all  database  related  activities.  He  is  involved  with  the 
* 

dailv  decisions  and  activities  which  have  immediate  impact 
upon  the  organization’ 5  operational  data  bases.  The  DBA  is 
not  overly  concerned  with  data  modularity,  ex tendabi 1 i ty,  or 
utility.  Data  modularity  is  the  ability  of  a  data  structure 
to  accommodate  more  easily  changes  to  the  information 
requirements  of  the  organization.  Data  ex tendab i 1 i ty  is  the 
ability  of  the  data  structure  to  accommodate  additions  or 
deletions  to  instances  of  data  without  affecting  the  desiqn 
of  the  structure  or  the  programs  that  use  the  data.  Data 
utility  is  the  ability  of  a  data  structure  to  satisfv  the 
information  needs  of  a  variety  of  end  users. 


DATA  ADMINISTRATION  VS.  DATA  BASE  ADMINISTRATION 
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Data  Admini stration  vs.  Database  Administration 


D. 


DATA  ADMINISTRATION  AT  NAVSUP 


In  November  1984,  NAVSUP  reorganized  the  Inventory  and 
In-formation  Systems  Directorate  (SUP-04)  in  a  move  to  help 
gain  control  over  current  and  -future  systems  development.  A 
major  point  prompting  the  reorganization  was  the  fact  that 
NAVSUP  was  supporting  development  of  separate  information 
systems  without  any  integration  between  those  systems.  As 
part  of  the  reorgan i z at  1  on  of  SUP-04,  a  data  administration 
branch  was  created  (SUP-0414)  as  part  of  the  Information 
Systems  Management  and  ADP  Security  Division.  Its  primary 
objective  is  to  develop  a  corporate  data  plan  and  logical 
data  model  for  NAVSUP  that  will  maximize  sharinq,  minimize 
redundacy  and  coordinate  all  data  flow  within  the  Naval 
Supply  System  and  its  interfaces  with  external  systems. 

The  majority  of  the  Data  Admi ni strat i on  Branch’s  effort 
to  date  has  been  with  defining  goals  and  implementing  the  DA 
function  at  NAVSUP.  The  branch  has  created  the  following 
objectives  and  a  timetable  for  the  next  two  veers: 

Mar  86  IMPLEMENT  THE  DATA  ADMINISTRATION  FUNCTION 

Staffing  POM  and  Recruitment 
NAVSUP  Corporate  Requirements 
Mission  Statement 


June  86  DEFINE  AN  OVERALL  INFORMATION  SYSTEM 
ARCHITECTURE  TO  SUPPORT  NAVSUP  BUSINESS 

FUNCTIONS 

De-fine  Current  Initiatives 
Create  NAVSUP  Steering  Committee 
Develop  NAVSUP  Business  Model 
Develop  Information  Architecture 

Dec  86  DEVELOP  DATA  ARCHITECTURE  TO  SUPPORT  THE 
NAVSUP  INFORMATION  SYSTEMS  ARCHITECTURE 

Desiqn  NAVSUP  Loqical  Data  Model 
Develop  Corporate  Data  Dictionary 

Jun  87  DEVELOP  A  NAVSUP  TECHNICAL  PLAN 
ENCOMPASSING  TELECOMMUNICATIONS,  OFFICE 
AUTOMATION,  AND  OTHER  EXISTING  NAVSUP 
INITIATIVES 


Document  Systems  Hardware  and  Software 
Develop  Systems  Concept  Paper 
Perform  Input  Analysis 
Develop  Technical  Plan 

The  above  objectives  support  goals  of  (1)  developing  the 
overall  objectives  of  the  data  administration  function  and 
secure  their  endorsement  by  top  management;  (2)  determining 
NAVSUP’ s  DA  scope,  in  terms  of  both  subject  matter,  and 
organi zat i onal  components  and  programs;  <3>  assigning 
overall  authority  and  responsibility;  and  *4.>  promulgating 
overall  or  gani rational  pol  icy.  According  to  its  mission 
statement,  the  data  administration  branch  is  dedicated  to 
providing  a  systematic  plan  for  developing  standards  and 
policies  which  ensure  ultimate  vertical  and  horizontal 
integration  of  data  among  the  various  NAVSUP  and  external 
i.  n  f  o rmati  on  systems. 
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Although  the  branch  has  been  poorly  staffed  since  its 


inception,  a  considerable  amount  of  headway  has  been  made 
towards  achieving  its  first  year  goals.  An  initial  decision 
has  been  made  for  SUP— 0414  to  be  the  proponent  for  all 
NAVSUP  information  resources  and  to  develop  the  DA  plan 
while  FMSO  is  being  tasked  to  accomplish  the  DA  tasks.  The 
following  is  a  list  of  SUP-0414  and  FMSO  functions  as 
currently  defined: 

SUP-0414  FUNCTIONS 

1.  Develop  and  maintain  a  NAVSUP  Corporate  Data  Plan 
and  Logical  Data  Model  to  reflect  the  data 
structures  required  to  support  the  information 
requirements  of  the  Naval  Supply  System. 

2.  Initiate  and  develop,  in  coordination  with  the 
Planning  and  Policy  Branch,  NAVSUP  standards  and 
procedures  related  to  data  resource  management, 
including,  but  not  limited  to,  Data  Dictionary 
Specification  Standards  and  Data  Element  Naming 
Convent i ons. 

7 .  Serve  as  NAVSUP  arbiter  to  review  and  resolve  data 
resource  issues  within  ADP  program  development. 

4.  Review  Data  Communication  Requests  to  insure 
compliance  with  Data  Administration  Standards  and 
Procedures . 

5.  Develop  and  implement  Data  Element  Naming 
Standards  and  Policies  for  all  NAVSUP  ADP  systems. 

6.  Develop  policy  and  procedures  for  data  transfer 
across  all  NAVSUP  networks,  including  data 
download  to  mi crocomputers. 

T.  Manage  development,  implementation,  and 

maintenance  of  the  Corporate  Data  Dictionary. 

8.  Act  as  navruF'  1 1  ason  with  all  external.  data 
systems  within  New,  DUD,  and  civilian  agencies 
a  nid  da<"  a  st  an  dat'd  l  c  at  i  on  efforts. 
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9.  Review  System  Life  Cycle  Maintenance  Documentation 
■for  adherence  to  Data  Administration  Policies  and 

Procedures. 

10.  Develop  policy  and  standards  for  loqical  data  base 
design  for  all  NAVSUP  system  development  projects. 
Conduct  post  implementation  reviews  to  insure 
compliance  to  standards. 

11.  Develop  NAVSUP  policy  and  standards  for 
initiatives  that  access  any  data  base,  both 
Corporate  and  private. 

FMSO  Functions 

1.  Perform  system  planning. 

2.  Provide  access  procedures  and  monitoring  for  all 
databases. 

3.  Perform  data  and  impact  analysis, 

4.  Assist  NAVSUP  DA  Branch  in  determining 
Headquarter ’ s  Corporate  data  requirements. 

5.  Provide  input  to  policy. 

6.  Implement  corporate  data  model. 

7.  Determine  and  maintain  a  record  o+  relationships 
among  databases. 

8.  Develop  corporate  data  dictionary. 

9.  Monitor  quality  and  inteqrit  -  of  data. 

1.0.  Function  as  technical  DA  expert. 

it.  Establish  documentation  standards  for  database 
systems. 

12.  Conduct  formal  DA  training. 

13.  Evaluate  various  automated  tools  for  DA 
devel op men t , 

14.  Serve  as  principle  consultant  on  Database  design 
projects  and  audit  trails. 


f-rom  the  above  lists,  it  can  readily  be  seen  that  SUP-0414 
has  a  good  idea  of  what  it  wants  to  accomplish  but  must  rel  / 
heavily  on  FMSO  to  do  so.  What  remains  to  be  seen  is  how 
much  top  management  support  SUP-0414  will  be  given.  The 
next  step  tor  NAVSUP ' s  Data  Administration  Branch  is  to 
develop  the  NAVSUP  DA  Directive  to  outline  all 
responsibilities  and  establish  its  corporate  policy. 

E.  DATA  ADMINISTRATION  AND  VERTICAL  INTEGRATION 

One  of  the  goals  formulated  by  NAVSUP  in  its  strategic 
plan  is  to  "Develop  databases  which  support  the  single 
update  of  related  data  and  provide  the  required  views  of 
that  data  to  all  levels  of  the  work  force"  LRef  163.  To 
achieve  that  goal  requires  the  integration  of  NAVSUP’ s 
information  systems  both  vertically  and  hor i zontal 1 y.  In 
relation  to  the  three  information  systems  discussed,  SUADPS 
REAL-TIME,  UADPS-SP  and  UICP,  vertical  integration  involves 
transferring  information  from  one  system  to  another,  i e. . 
from  ship  to  stock  point.  Horizontal  integration  involves 
passing  information  from  organization  to  organization  on  the 
same  level,  ie. .  from  stock  point  to  stock  point. 

Integration  of  information  systems  requires  compatible 
hardware  and  software  and  well-developed  data  bases.  NAVSUP 
has  addressed  the  problem  of  hardware  and  software 
compatibility  and  in cl uded  those  requirements  in  the 
spec  i  f  i.  cat  i  one  for  the  SPAR  system  acquisition,  Indeed,  the 


technology  to  allow  communi cat  1  on  between  the  three  systems 
exists  today.  Additionally,  at  the  completion  ot  the  SPLICE 
project,  the  capability  -for  UADPS-SP  systems  to  communicate 
through  the  DON  will  be  achieved.  However,  compatible 
systems  cannot  overcome  weaknesses  in  data  organization. 

How  valuable  is  having  integrated  information  systems  1 f  the 
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needed  data  does  not  exist,  or  no  one  knows  whether  the  data 
is  available  or  not,  or  if  conflicting  data  exists,  or  if 
effective  controls  over  the  use  of  the  data  are  lacking? 

The  above  weaknesses  exist  in  most  organizations' 
information  systems  and  are  the  primary  focus  of  data 
admi ni strat i on . 

NAVSUP  headquarters  has  a  definite  problem  with 
integrating  its  three  information  systems  because  its 
overal  1  ADR  environment,  has  never  existed  in  stages  4  and  5 
of  Nolan’s  cycle:  Integration  and  Data  Administration, 
ihese  two  stages  are  character i zed  by  the  integration  of 
applications  vice  information  systems  and  by  the  development 
and  management  of  data  bases.  All  of  NAVSUP  s  previous 
systems  utilized  file  structures  based  on  applications, 
AiJADPS  REAL-TIME  has  retained  its  redundant  file  structures. 
UIC  P  R'ESYSTEMI  ZATIGN  is  being  designed  around  its  current 
appl  iration;.  The  redesign  of  UADPS-SP  is  NA’vSUP  '  s  first 
attempt  at  using  modern  database  structures  and  database 
management  systems  as  well  as  resfructuri nq  spp l i cat  ions. 


catch  up  to  today’s  technology.  This  is  primarily  due  to 


the  requirement  for  NAVSUP  to  keep  its  original  systems 
throughout  the  period  that  comparable  organ i z at  1 ons  were 
implementing  data  base  systems.  Another  negative  factor  is 
the  decentral  1  zed  environment  in  which  the  NAVSUF  systems 
have  evolved.  For  two  decades,  the  coordination  of  the 
three  systems  at  the  ship,  stock  point,  and  ICF  level  was  a 
low  priority  at  headquarters. 

In  an  effort  to  support  the  goal  of  integrated 
information  systems,  NAVSUP’ s  strategic  plan  requires  the 
establishment  of  a  formal  SPAR/ I CP  RESOL ICTATI ON/ SUADPS 
application  working  group  to  identify  and  justify 
integration  opportunities.  Although  it  initially  restricts 
the  concept  of  integration  to  the  three  current  systems  and 
their  current  applications,  it  is  a  beginning.  For  this 
integration  team  to  be  effective,  it  should  be  relatively 
independent  of  the  management  hierarchy  in  order  to  avoid 
the  power  struggles  of  each  of  the  current  systems  and  to 
escape  the  risk  aversion  attitude  of  corporate  headquarter s . 
The  accessibility  of  data  creates  a  multitude  of  questions 
regarding  NAVSUP’ s  traditional  support  structure.  The 
business  of  providing  supply  support  to  the  operating  units 
of  the  Navy  remains  the  same.  However,  NAVSUP  should  take 
advantage  of  technological  advances,  look  at  the  current 
automated  applicat ions  and  funct ions,  and  ask  whether  it  can 
np  done  better  with  new  technology.  For  i  nstance,  if  a  shir. 
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has  access  to  the  worldwide  inventory  of  parts,  does  it  need 
to  submit  a  referrral  to  the  closest  stock  point  if  it  is 
not  carried  there?  Why  not  refer  the  requisition  to  the 
stock  point  or  activity  that  has  the  part  available  and 
avoid  the  additional  referral  to  the  I CP?  In  a  segregated 
int-ormation  or  gam  z  at  1  on  ,  the  answer  would  be  because  that 
function  does  not  exist  at  the  shipboard  level.  It  is  the 
ICR’s  responsi bi I i ty .  Finding  the  optimum  solution  to 
questions  created  by  the  new  availability  of  data  will  be 
difficult  at  best.  It  requires  a  total  rethinking  of  the 
processes. 

Many  of  the  questions  that  the  integration  team  will 
address  should  have  been  answered  prior  to  the  beginning  of 
the  IJICP  RESYSTEM  I Z  AT  I  ON  project  or  at  least  the  Information 
Engineering  portion  of  the  SPAR  project.  An  example  is  the 
interfaces  needed  between  the  three  current  systems.  That 
guidance  should  have  originated  from  headquarters  as  part  of 
a  top-down  planning  technique  of  the  strategic  requirements 
phase.  The  redesign  team  at  FMSO  used  a  bottom-up  approach 
to  define  the  probable  interfaces.  No  decision  has  been 
made  about  whether  all  the  interfaces  are  correct  and 
complete.  In  the  meantime,  FMSO  is  beginning  to  feel  the 
pressure  of  command  dictated  completion  dates. 

The  objectives  of  Data  Adm t ni str at i on  support  the  goal 
of  integrated  information  systems.  Data  is  the  most 
important  component  of  information  systems.  1  he  i  ev  »  3 


knowing  what  data  exists  and  where  it  is  located 


The 


functions  of  the  DA  include  developing  and  maintaining  a 
data  dictionary  which  can  answer  queries  regarding 
information  resources.  For  instance,  if  NAVSUP  needed  to 
know  the  data  entities  and  applications  containing  standard 

MILSTRIP  requisition  information  such  as  QUANTITY-ON-ORDER, 

* 

the  Data  Admi ni strator  should  be  able  to  respond  with 
information  detailing  the  fact  that  QUANTITY-ON— ORDER  is 
represented  by  six  different  variable  names  in  23  different 
programs  and  be  able  to  list  them.  Data  dictionary 
information  is  extremely  valuable  in  systems  integration. 
Therefore,  the  integration  team  should  study  the  overall 
Data  Administration  organization  at  NAVSUP  to  help 
understand  the  complexities  of  structuring  data  to 
facilitate  system  interfaces.  NAVSUP  may  have  begun  its 
Data  Administration  program  too  late  to  play  out  its 
complete  role  in  the  information  engineering  project  for 
SPAR.  However,  NAVSUP  is  not  just  in  the  business  of  suppl 
support;  it  is  also  involved  in  retail  operations, 
petroleum,  household  goods  shipments  and  many  other 
information-dependent  functions.  The  establishment  of 
effective  integrated  systems  in  one  area  mav  pave  the  way 
for  additional  improvements  in  other  information  systems. 
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F.  PROBLEMS  WITH  DATA  ADMINISTRATION  AT  NAVSUP 

The  establishment  of  the  data  administration  -function  at 
NAVSUP  is  now  at  a  crossroads.  The  definition  of  goals  and 
objectives  for  DA  are  relatively  complete.  Implementation 
of  those  objectives  and  achieving  the  qoals  will  not  be  as 
easy.  Top  management  at  headquarters  must  dedicate  support 
and  make  a  decision  regarding  the  scope  of  the  DA  function 
to  give  the  Data  Administration  Branch  the  power  it  needs  to 
fulfill  its  responsibilities.  SUP-0414  has  encountered  many 
of  the  same  problems  in  establishing  the  data  administration 
function  as  its  counterparts  in  other  large  corporati ons. 
Among  those  are  lack  of  expertise  and  resistance  to  change. 
Other  problems  such  as  the  budget  constraints  for  the  DA 
evolution  are  unique  to  a  military  or  government 
environment.  The  following  is  a  list  of  factors  that  are 
currently  hindering  the  proper  development  and  effectiveness 
of  the  data  admi ni strat i on  function  at  NAVSUP: 


1.  Incomplete  staffing  of  DA  E-tranch:  The  current 
plan  allocates  three  positions  in  SUP-0414.  Only 
one  position  remained  filled  for  the  past  10 
months  and  it  is  now  vacant.  Recruitment  does  not 
seem  to  be  a  top  priority. 

2.  Limited  ADF'  background  of  staff:  The  one  staff 
member  previously  employed  devoted  the  majority  of 
her  time  getting  up  to  speed  on  ADP  terminology 
and  database  techniques.  This  has  resulted  in  a 
lack  of  credibility  with  the  principal  players  at 
FMSO  and  the  information  systems  sponsors  at 
NAVSUP . 

3.  The  DA  Branch’s  location  in  NAVSUP ’ S 
organizational  structure  is  too  low  to  solicit 


cooperation  -from  in-formation  systems  sponsors: 
SUP-0414  is  competing  against  the  firmly 
entrenched  support  structures  o-f  the  three  current 
information  systems.  DA  objectives  which  require 
a  rethinking  o-f  application  -functions  are 
unachievable  in  the  current  structure  without 
power  struggles. 

Attempting  to  establish  a  DA  environment  in  a 
decentral i zed  ADP  environment:  NAVSUP 
headquarters  has  no  control  over  the  data  or  the 
applications  development  o-f  its  information 
systems.  Data  is  processed  around  the  world  while 
the  design  and  development  of  the  three 
information  systems  is  accomplished  by  two 
separate  activities.  Implementing  data  standards 
will  be  more  difficult  than  if  NAVSUP  functioned 
under  a  centralized  ADP  concept. 

Attempting  to  implement  DA  functions  in  time  to 
determine  data  needs  for  SUADF'S  REAL-TINE/  SPAR/ 
UICP  interface:  If  data  admi ni stration  is  to 
effectively  support  the  information  engineering 
concept,  data  needs  and  interfaces  must  be 
determined  prior  to  system  design.  SUP-0414  is 
way  behind  the  power  curve  regarding  the  current 
development  of  information  systems.  The  needs  of 
the  three  projects  may  be  dictating  the  DA  efforts 
instead  of  the  true  needs  of  the  corporation. 

Corporate  inexperience  with  database  management: 
Data  administration  functions  evolved  from 
database  admi ni strat i on .  It  is  difficult  to 
determine  long  range  and  overall  data  needs 
without  experience  with  designing  and  operating 
specific  databases. 

Data  Admi ni strati  on  conflicts  with  the  traditional 
organ i z at  1 onal  philosophy  of  NAVSUP:  Headquarters 
is  uncomfortable  with  the  concept  of  DA  because  it 
is  historically  a  reactive  or  risk  aversion 
centered  organization.  The  lack  of  ADP  oriented 
personnel  at  headquarters  restricts  the  knowledge 
of  information  engineering  and  the  value  of 
wel  1  -i  nteqr  a  ted,  data. 

Current  time  schedule  for  achieving  DA  functions 
waits  too  long  before  tangible  benefits  are 
achieved:  An  organization  such  as  NAVSUP  needs  to 

see  tangible  benefits  in  order  to  justify  the 
expense  of  the  DA  function.  in  the  government. 


this  is  especially  a  problem  due  to  the  budget, 
process  and  current  deficit  spend! nq  concerns. 

The  above  problems  are  by  no  means  -fatal  to  the  data 
administration  function.  However,  collectively  they 
critically  restrict  the  evolution  of  the  DA  function  at 
NAVSUP.  If  NAVSUP  is  serious  about  providing  integrated 
data  throughout  its  organisation,  then  it  must  dedicate  top 
management  resources  to  solve  these  problems.  SUP-0414  has 
identified  the  needed  tasks.  However,  no  real  authority 
exists  to  ensure  they  are  performed. 


V.  CONCLUSIONS 


The  world  of  information  systems  design  has  undergone  a 
remarkable  change  since  NAVSUP  first  implemented  SUADF'S, 
UADPS-SP  and  UICP.  Unlike  many  corporations  which  have 
implemented  database  systems,  NAVSUP  is  not  afforded  the 
opportunity  to  make  an  easy  transition  from  the  application 
centered  projects  to  the  concept  of  information  engineering 
and  integrated  systems.  Data  Admi ni strati  on  is  one 
management  function  that  can  allow  NAVSUP  to  eventually 
catch  up  with  its  information  needs  if  it  is  given  enough 
support . 

The  UADPS-SP  redesign  effort  will  be  the  key  to  NAVSUP 
having  integrated  information  systems.  SUADF'S  REAL-TIME  and 
UICP  have  already  been  committed  to  appl 1  cation-dependent 
file  structures.  UADPS-SP  will  be  the  prime  interface 
vehicle  for  the  integration  of  data.  The  FMSO  UADPS-SP 
Redesign  Team  has  taken  the  lead  in  performing  the  strategic 
requirements  function  of  information  engineering.  It  must 
be  completed  prior  to  the  design  of  the  logical  database 
structure.  NAVSUP  should  respond  as  soon  as  possible  to 
their  queries  regarding  the  desired  functional  activities  of 
UADPS-SP. 

Aside  from  providing  token  input  regarding  naming 
standards,  the  NAVSUP  Data  Admi ni strati  on  Branch  has  been 
ineffective  in  assisting  the  information  engineering 
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project.  Its  obvious  weakness  has  been  in  staffing.  Now 
that  the  goals  and  objectives  -for  data  administration  have 
been  delineated,  NAVSUP  should  decide  what  it  is  going  to  do 
with  its  organ i z at i on .  DA  cannot  evolve  ef  f  ecti  vel  y  as  it 
is  currently  located  and  manned.  1+  a  true  IE  effort  is 
envisioned,  it  should  be  moved  up  the  NAVSUP  organization  to 
either  the  SUP-OOX  or  SUP-04  level  to  give  it  the  full 
"top-down"  support  it  requires.  Otherwise  it  should  be 
moved  to  FMSQ  where  the  knowledge  of  database  management  and 
design  resides  and  where  it  can  realize  its  objectives 
relating  to  integrated  data  design.  Then,  after  tanqible 
benefits  become  evident,  consideration  can  be  given  to 
expanding  the  scope  of  DA  and  migrating  it  to  headquarters 
for  higher  level  admi ni str at i ve  purposes. 

The  UADPS-SP  redesign  project  is  not  a  true,  top-down 
information  engineering  project.  Nevertheless,  many  of  the 
issues  the  FNSO  team  is  addressing  are  top  management 
issues.  This  results  in  the  equivalent  of  a  "middle  out" 
approach  to  IE  which  makes  the  development  of  a  corporate 
data  dictionary  exceedingly  difficult.  The  NAVAL  SECURITY 
GROUP  for  example  required  six  months  just  to  standardize 
400  names  for  a  corporate  dictionary.  UADPS-SP  is  much  more 
involved.  With  the  current  time  restrictions  placed  on  the 
redesign  effort,  serious  consideration  should  be  given  to 
developing  a  dictionary  which  is  much  smaller  in  scope  and 


which  facilitates  the  transition  to  a  data-oriented 


UADPS-SP 


If  this  is  successful,  then  a  concept  known  as 


selective  retrofitting  can  be  used  to  incorporate  new 
applications  as  they  arise  and  evolve  towards  a 
comprehensive,  integrated  corporate  dictionary. 

Today,  there  is  a  critical  need  to  integrate  information 
systems  within  NAVSUP.  Information  needs  throughout  the 
organization  have  increased  tremendously.  The  capability  to 
have  an  integrated  system  exists,  if  NAVSUP  can  gain  control 
of  the  data.  SUADPS  Real-Time,  SPAR,  and  UICP 
RESYSTEMI 2ATI0N  began  at  different  times  and  are  in 
different  stages  of  development.  For  NAVSUP  to  properly 
integrate  those  systems  to  allow  worldwide  access  to  data  at 
all  three  levels  of  the  logistic  chain,  it  will  have  to  free 
data  design  from  applications.  An  effective  data 
administration  organization  is  needed  to  ensure  the  data 
requirements  of  the  overall  corporation  are  satisfied. 
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